This PR:

1. Fixes a false-positive confetti animation in the gift card redemption flow when the user already has an open Lightning channel.
2. Fixes the gift sheet re-opening after an app language change re-delivers the launching intent.

Description

1. False-positive confetti

BlocktankRepo.claimGiftCodeWithLiquidity previously returned success as soon as Blocktank's giftPay HTTP RPC returned — but that response only confirms the LSP accepted the request, not that the LN payment actually landed. If Blocktank's background payer subsequently failed to route the HTLC, Bitkit still played confetti and surfaced a "received" sheet with the requested amount, while no incoming payment ever arrived.

The repo now subscribes to LightningRepo.nodeEvents for the Event.PaymentReceived matching the freshly-created invoice's payment hash before triggering giftPay, then awaits that event with a 45 second timeout. On timeout it throws ServiceError.GiftClaimPaymentNotReceived, which the existing error handler in GiftViewModel routes to the standard GiftRoute.Error screen. The success result reports the actual received sat amount instead of the requested amount.

The without-liquidity path (channel open + openChannel) is unchanged — that path already blocks on the funding transaction.

2. Intent re-delivery on Activity recreate

When the app language is changed, Android destroys and recreates the Activity, re-delivering the original launching intent. MainActivity.onCreate was unconditionally calling handleDeeplinkIntent(intent), so any deeplink-driven flow (gift sheet, send sheet, pubky auth, etc.) re-fired on the locale switch.

onCreate now only processes the launching intent on a fresh start (savedInstanceState == null). New deeplinks that arrive while the app is running are still handled via onNewIntent.

Preview

N/A

QA Notes

Reproducing the failure path

The originally-reported gUCdzXfm12V71xztGzDoiQ-3000 is now exhausted and returns GIFT_CODE_USED_UP (a separate, already-handled path), so it can no longer reproduce the false-positive. To exercise case 1, use one of:

• Coordinate with the Blocktank team to provide a code whose LSP-side LN payer is in an unpayable state (accepts the HTTP request but cannot route the HTLC).
• Issue a valid code via the regtest blocktank harness, then disconnect the LSP peer / cut network between scanning the QR and the HTLC settling, so the inbound HTLC never arrives. giftPay returns success but Event.PaymentReceived never fires.

Regtest helpers

Fire the gift deeplink directly without scanning a QR (replace the package id per flavor — to.bitkit.dev for dev/regtest, to.bitkit.tnet for testnet, to.bitkit for mainnet):

adb shell am start -a android.intent.action.VIEW -d "bitkit://gift-gUCdzXfm12V71xztGzDoiQ-3000" to.bitkit.dev